Videoconferencing and streaming media systems for use over data networks are known in the art. A variety of techniques for implementing such a conference have been published and in use for at least a decade.
One “brute force” manner in which a videoconference may be implemented over a data network involves the broadcasting of packets in multiple copies to all other conferees. Specifically, each member of a videoconference that converts the information into the packets, may duplicate the packets and transmit them over to the data network, with each copy of the packet containing a separate one of the other conferee's addresses. In this manner, each packet produced is transmitted plural times, to different addresses.
An inefficiency with the foregoing is that much of the network bandwidth is wasted. The foregoing method does not take advantage of the fact that a single version of the packet could be sent partially through the network, where it may be split and sent to plural recipients. Additionally, processing power in each transmitting terminal is wasted, since each terminal must duplicate the same packet plural times.
A proposed solution to the foregoing system was developed during the 1990s by an Internet standards group and is termed “Multicast.” In multicast technology, a single copy of the packet traverses the data network until the last possible point where it may be replicated and still reach plural recipients. The packet is then replicated at that point. An example, with respect to FIG. 1, will help clarify. Consider a multicast packet originating at node 106 which is destined for both node 102 and 101. Multicast technology might employ a routing algorithm that routes the packet from 106 to 110, and from 110 to 108. However, the routing algorithm at node 108 would recognize the packet as a multicast packet, duplicate it, and transmit copies to each of nodes 101 and 102. Thus, while the packet must be replicated, it is transported as one packet for as long as possible until being copied to produce two or more packets.
It will be recognized by those of skill in the art that the above technique requires a specialized set of addresses to perform multicast conferencing. More specifically, it can be appreciated that the network 100 needs to be capable of routing packets in a conventional fashion from one node to the next when multicast packets are not at issue. Thus, with respect to conventional packet switching, each of the nodes in network 100 must be capable of examining a packet, performing a table lookup to determine the next node to which such packet should be routed, and sending the packet. With respect to multicast technology, each node must be capable of recognizing the address as a multicast address and duplicating the packet in a manner such that copies of the packet get routed to the next node on their way to various conference participants.
Further complicating the situation is the fact that the conference participants in any conference change on a dynamic basis. Thus, a particular multicast address may be utilized to identify a first conference at a first time, and a second conference at a second time. Each multicast address represents all of the conference participants and the nodes are programmed such that any packet with the multicast address is appropriately treated, duplicated where necessary, and sent to plural recipients.
Another problem with the foregoing is the fact that the multicast addresses are dynamic. More specifically, typically a band of addresses are reserved for multicast conferences. When a conference is desired to be started, the originator of the conference would randomly pick one of the band of addresses reserved for multicast. This band of addresses is referred to as Class D addresses.
To initiate the conference once the address is picked, a specialized software tool called a session directory (“SDR”) must announce to other network nodes that the session is to be on the particular random Class D address chosen. Users desirous of joining the conference must then attempt to configure in a manner to participate.
If a particular user's workstation is not turned on at the time that the announcement of the conference is made from the originating terminal's SDR, then the terminal, when later turned on, will have no information regarding the videoconference. Since the originating SDR would typically only repeat the conference information in 10-20 minute intervals, it could be a significant amount of time before a user knew what conferences were proceeding. Moreover, the entire process involves random dynamic addresses, software tools such as SDR, directories, and a variety of other complex software tools and files. In short, the system was complicated and cumbersome.
A slight improvement occurred in the late 1990s. A certain subset of the Class D addresses were declared to have special properties and were defined as being applicable in specified geographic areas. Since the specified geographic area may include, for example, a community of interest such as a particular corporation, or set of buildings, there is little chance of conflict among users competing for the same Class D addresses. Thus, it became possible to permanently assign certain administratively scoped addresses for specific multicast use.
The foregoing system does not take advantage of the full capability of such administratively scoped addresses. Accordingly, there exists a need in the art for a technique of performing multicast which permits flexibility and ease of use in multicast systems, and specifically, in the use of administratively scoped multicast systems.